The OpenStack Object Storage system, aka “Swift,” is a multitenant, highly scalable, and durable object storage system designed to store large amounts of unstructured data at low cost. Highly scalable means that it can scale from a few nodes and a handful of drives to thousands of clustered machines with multiple petabytes of storage.
Swift is designed to be horizontally scalable so there is no single point-of-failure. Swift is used by businesses of all sizes, service providers, and research organizations worldwide. It is typically used to store unstructured data, such as documents, Web and media content, backups, images, and virtual machine snapshots. Originally developed as the engine behind the RackSpace Cloud Files storage service in 2010, it was open-sourced under the Apache 2 license as part of the OpenStack project. With more than 100 companies and thousands of developers now participating in the OpenStack project, the usage of Swift is increasing rapidly.
Swift is not a traditional file system or a raw block device. Instead, it enables users to store, retrieve, and delete objects, with their associated metadata, in containers via a RESTful HTTP API. Developers can either write directly to the Swift API or use one of the many client libraries that exist for all popular programming languages, such as Java, Python, Ruby, and C#. Some key characteristics of Swift, which differentiate it from other storage systems, include that is was designed to store and serve content to many concurrent users, run on industry-standard x86 servers, and manage its storage servers with no additional vendor specific hardware needed.
Several services may run on a Swift cluster, including proxy, account, container, and storage services. Proxy services handle the external communication with clients and the storage services handle the storage and maintenance of data stored in Swift. An account in Swift represents a user in the storage system. Unlike other storage systems which create volumes, Swift creates accounts, which enable multiple users and applications to access the storage system at the same time. Accounts and containers store key information about themselves in separate databases that are distributed throughout the system (Swift Account DB). Swift accounts can create and store data in individual containers. Containers are namespaces used to group objects within an account. Although containers cannot be nested, they are conceptually similar to directories or folders in a file system.
Once a cluster has been configured, data is put into and taken out of it over a RESTful HTTP API. By default Swift stores and maintains multiple copies of each piece of data, with each copy being kept as far from the others as possible, e.g. different regions, zones, and drives. This ensures data integrity and accessibility.
To manage a Swift cluster, a central management system (or “controller”) provides operators (e.g. the example Bob's Business shown in FIG. 1) with a browser-based interface and system to easily manage Swift nodes, configure networking, and user accounts for their organization's cluster. Operators use the Controller for monitoring, authentication integration, alert, system statistics, and reporting. These statistics and reports are based on accurately aggregated data and allow operators to determine storage utilization relating to chargeback and billing. This is useful for customers who leverage the multi-tenancy of the Controller to allow their own customers (e.g. the example Alice's Company as shown in FIG. 1) to use and store data via the Controller.
The Controller is accessed online and its management of the cluster is independent of the data storage performed by the nodes. When a multitenant central management system is accessed over an insecure network by customers on other unknown networks, this creates a set of challenges including the need for a communications channel between the central management system and the nodes that is secure and persistent over the Internet.
For a central management system with multitenant, multi-network distributed nodes there is a need for secure management and monitoring. The central management system needs to establish a one-to-many connection to all the nodes, while the client nodes need a one-to-one connection with the central management system. Once established, the connection must provide bidirectional communication to allow processes (e.g. daemons executing on the nodes and central management system) to securely communicate with each other as though operating on the same network. Embodiments of the present disclosure describe novel systems and methods that provide for secure channels that can:                (1) ensure that nodes from other tenants are never aware of or able to access the communication channel of another tenant; and        (2) be easily and securely reestablished after a network interruption.        